Introduce class hierarchy to support common Contest behaviors #125
Conversation
thank you! I was wanting to do that, but could not find the keyword. |
|
The code looks good to me but I'm still a newbie here :-) Conceptually the abstraction seems good. |
I agree with your suggestions. Initially, the contests where all table driven with lots of switch statements. This class hierarchy removes the switch/case statements, but we still have lots of classes, one for each contest. I agree that additional table-driven techniques could be used as we identify common behaviors across contests. The tricky part I'm focusing on now is dynamic exchange types where the exchange changes by contest. I missed this during my initial design and am reworking my approach now. To your second idea, yes, N1MM does have the UDC (User-defined contests) - that would be cool to perhaps support those someday. I've been working with Steve, N2IC, on N1MM integration - I'm hoping that this multi-contest version can work with N1MM so N1MM can be used to enter contest data with MR generating the sounds. |
|
I discovered another issue with the above code. The FD, Wpx, WW, CWOPTS, and NaQP contests only need to read their call history files one time. Only the future ARRL DX Contest will require reloading if the user's callsign changes (part of a future integration). |
This refactor step is necessary to prepare for dual exchange contests, including ARRL DX Contest (part of issue #62). Previous refactoring steps are covered in PR #132 and PR #125. Changes in this PR include: - after user callsign edits, SetMyCall is called. - SetMyCall calls Tst.OnSetMyCall which will extract any contest-specific information (e.g. in ARRL DX Contest, US/CA stations work only DX and DX works only US/CA stations). - call history file is now loaded after the user starts the contest using the RUN button. This simplified the reload logic in case the user callsign had changed. - move logic from each derived call history reader into the base class TContest.OnContestPrepareToStart function.
Implements a common class hierarchy to support contests. contest-specific behaviors will be implemented in the various derived contests. See Issue #124 for a UML Class Diagram showing this hierarchy. This refactoring introduces the base TContest class along with 5 derived subclasses.